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In 1974, the railroad industry initiated the AAR Freight 
Car Utilization Research/Demonstration Program to examine a 
dozen different aspects of the increasingly burdensome problems 
The program is a cooperative effort 
between the railroad industry, its customers, the supply indus- 
Its objective is to improve the pro- 
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This document is the result of the efforts of Task Force 
5, Phase II, of the Freight Car Utilization Research/Demonstra- 
Task Force 5 was assigned the responsibility of 
evaluating the current status of railroad car distribution sys- 
tems and summarizing relevant research. 
also charged with pointing the direction for development of 
the next generation of car distribution systems. 
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Identifying practices that contribute to idle standing 
time, unnecessary movement, slow transit, or below- 
capacity loading of freight cars. 





This report addresses primarily the last of these objec- 
tives, by detailing the feasibility of a highly automated 
empty car distribution system for Missouri Pacific Railroad. 
Missouri Pacific Railroad was asked by Task Force II-5 to 
undertake this work because it has today one of th 
tralized and computerized car management systems in North 
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Informing the rail transportation community 
findings and conclusions. 


Task Force 5 met initially in December 1977 and completes 
A separate report summarizes the 








its work with this report. 
conclusions and recommendations of the Task Force. 
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a The members of the task force were: 
Phase I of the Program, extending from January 1975 through 
focused on defining and measuring the problems. 

work was managed under six task forces of manpower contributed 
by railroads, shippers, suppliers, and government, supported 

by a full-time program statt, and numerous consultants. 
II and its follow-on projects have been devoted to f 
It is proceeding in a manner simi 
Phase I, but with substantial infusion of new pa | 
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1 Conversion — taá | 
technological and operational 


environment where the benefits can be quantified. 
logical question that can be addressed best by a pilot operation centers 
on the ability of available computer resources to solve the distribution 
problem in a time frame acceptable to the car distributor. 
operational problems that can be addressed only by a pilot operation cen- 
ters on the ability of the car distributor to review and 
model output in an acceptable time frame and on the beneiits to be gained 
implementation. 


to document understand utilization 
problem inevitably points, at 
of time which cars of every type spend empty. 
the natural consequence of locational and seasonal 
specialized equipment 
there also appear to be unexplained inefficiencies and an 


control or reduce the empty cycle. 


excessive percentage 


imbalances in demand, 
the need 


inability 







raliroads even 
the empty car-days and car-miles accumulated by the freight car fleet has 
Operating Department's 
Distribution Group 
car-miles 
requirements for cars with 
By attempting to manage the flow of empty cars from the time they are un- 
they are placed for the next 


Historically, and on most responsibility 




















ion System Overview | 
study examined 


system and the DSAI Car Distribution Model 
Car Distribution System. 
software, procedures, and reports required to support an enhanced system, 
and computer costs required to develop 


Transportation 
Transportation's charged with minimizing 
reducing both 
matching customers" the available car 
and estimated the MoPac manpower 
loaded until and implement such a system. 
attempt to 
in a manner that minimizes 


maximizes order-fill. 


load or delivered off 
that empty freight equipment on 
transportation and per diem costs, 
























Various efforts to improve the process of managing the empty treight 
have been addressed. 
deen the following: 


significance 
project are described in Sections 


Figure 6-1 










The development of the Missouri Pacific Railroad (MoPac) Trans- 


portation maintains 


+ 
in 


required to complete the project 





of system-wide empty-car requirements, and 
















Conclusions 







The development by Decision Systems Associates, Inc. (DSAI) oi 
distribution 
mathematically optimal algorithms for solving large-scale trans- 
portation problems. 








extremely  etficient, 







that a car distribution system that incorporates these 


opments wili result in significant improvements in car utiiization. and would 





The pilot 









MoPac-DSAI Study - Approach 


















Railroad, in cooperation with DSAI, conducted 
feasibility, desirability, 
DSAI model on 


implementation are: 







property. 
such a pilot 
























optimization 
technicaliy 


world car distribution 


procedura .ly 
function, and 

















To determine what benefits 
its customers from the exploitation of this technology. 





adopted for 
time frame 
was 


the use of the existing MoPac Car Distribution 
as the bases for an enhanced 


The study determined, in general 





describes the results 
scribes the current Missouri Pacific Car Distribution system, Section 3 
describes the DSAI model, and Section 4 describes the enhanced system. 














The primary tasks to be undertaken by MoPac during the course of the 
5 and 6 and are shown 
contains a schedule which shows the number of months 
required by MoPac to accomplish each task of the project and the sequence 
| to be accomplished. 
is 26 months. 








study 








The DSAI model currently restricts the number of car types (use 
for car type substitution) to seven; 





Since gondola supply and demand points are 
out the MoPac network, the opportunity for 
the empties are greater than i 
type movements; 













Gondola supply and demand 
gondolas is met by gondolas, with virtually no 
types; and the gondola suppiy is 
gondola demands with virtually no use of gondolas to meet non- 
gondola car-type demands. 


can be 












realized by the railroad 
substitution 
non-gondoia car 






to achieve 
least expenditure 
timely answers 
in such a system 
The principal 


study was 
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selected to provide 


estimated 
quest Lons 


to MoPac 
compiete the project are: 


programmer-analyst, 
man-wee ks 


management, 
and minutes of 




























Programmer-Analyst Cost: 2ll man-weeks 


The principa: 















Management Cost: man-weeks 










implement 






IBM Model 3033 Computer 13,710 minutes 






























cost of MoPac resources that would be applied to the pilot 


| | implemen- 
ion totals approximately $500,000. 






The estimated 
support the DSAI model 


(0 execute the CDC equipment and to modify, test, 


for the duration of the project 















are covered in 

























in Figure 6-1 















indicate 
enhanced Car Distribution System and conduct a pilot 
Missouri Pacific Railroad would not only be feasible but would also, 
car distributor's point of view, 
system would be a modification of 
incorporate the DSAI model as an 
implementation would optimize the distribution of general pur- 
throughout the MoPac 
dered in selecting gondolas for the pilot are as follows: 





















implementation on 


be desirable. 
the existing MoPac Car Distribution 
component. 














System. 





The main purpose of the computerized portion of the Car Distriouti 











interspersed 
movements 
they were 





Section 2 





MISSOURI PACIFIC CAR DISTRIBUTION SYSTEM 


Description 


The management of empty freight cars on the Missouri Pacific Railroad 
integrated system of Customer Service Centers, Equipment Control 
Officers, 
nations for empty cars. 


and a computerized system for automatically assigning desti- 


Missouri Pacific Railroad has a network of Customer Service 


each covering a defined geographic region of the railroad. Two 


of the primary responsibilities of each Customer Service Center are to 
determine shipper requirements for empty cars and to enter these require- 
into the computer system in the form of Shipper Car Orders. 
Shipper Car Order information comes to the Customer Service Center írom 
shippers and outlying agencies, and contains all the information 
needed to order a car. 


The Equipment Control Officers are located at the MoPac headquarters 
Louis, and their function is referred to as Central Car Control. 
Some of the principal activities of Central Car Control are: 


yen 
c 


Review Shipper Car Orders to determine specific demands fo 
empty cars; 


Review historic demand patterns to determine expected demands 
for equipment at various system locations; 

Look for cars that can be applied to Shipper Car Orders by 
reviewing lists of cars that are received in interchange, 
released from industry, released from hold statuses, and moving 
on trains; 


Apply cars to Shipper Car Orders; 
Change destinations of cars; 


r orders and instructions into the computer system to enable 
o automatically assign destinations to cars; and 


Maintain orders and instructions governing the automatic cispo 


Sition of foreign empties. 


to automatically assign a destination to every empty ca 


available for movement on the MoPac system. Car Distribution 
automatically assigns a destination to each empty car when it is: 


from industry, released from a hold status, received in incer- 


change, or when a specific request has been made for a new destination. 


Supports several priority levels of orders with des The destination specified in the Shipper Car Order is immediately 
applied unless the car is in a status that pronibits immediate appii- 
cation. If a car is currently applicd to another Car Distribution Oruer, 
1t is redestined per the Absolute Application. Absolute Application in- 
put is restricted to designated CRT devices located in the office of Cen- 
tral Car Control. 


for empty cars. When an empty car becomes avail- 
ıbutıon automatically assigns it to a destination from ti 
| ti the car satisfies. This destination may 
assignment, a Movement Instruction 
to direct cars from an area of 
e route/home route information 
it Controi personnel manually apply individua] 
to certain high priority special orders and Shipper Car Orders and 
personnel enter waybills on empty private cars. Special Instructions rank immediately below Absolute Application. 
They are manually applied against a specific car or cars, and override 
Orders and Instructions any other order, pool assignment, or waybill. 


uto- 


Car Distribution System uses orders and instructions to a The destination specified in the Special Instruction is immediately 
ally assign destinations to empty cars. These orders and instruc- | appiied to an empty car if it is in a status acceptable for application. 

are manually entered into the computer system by Central Car Con- If the car is loaded, with an online destination, the Special Instruction 
personnel. The particular order or instruction used by the system LS applied upon release empty. If the car is offline, or ioaded with an 
offline destination, the Special Instruction will be applied when the car 
LS received in interchange empty. 


^ 


a destination to a car is the highest ranking of all the orders 
instructions that match the car's attributes. 


The orders and instructions used by the Car Distribution 


r System and 
ir rank of priority are: 


A Special Instruction can destine a car online or offline to an Agent 
to a customer. If destined to an online Agent, the car may be applied 
a Shipper Car Order in that Agent's responsibility area. 
Absolute Application; 
nly Central Car Control can change the destination of an empty car 
Special instructions; moving on Special Instructions before it reaches its destination. 


Assignments Refere | by Absolute Control Orders; 


> 


Pool Assignments Referenced by Absolute Control Orders 
oy Movement Instructions; Pool Assignments rank immediately below Special Instructions 
car Distribution priority system unless referenced by Absolute Cont 
Commodity Pools; pn | Orders or Movement Instructions. This permits the diversion of cars 
their regular pool assignment to other temporary loading, either onlii 
or offline, without the entry of individual car initials and numbers, 
required by Special Instruction input. By referencing a particular 
Absolute Control Orders; with an Absolute Control Order, the priority is raised above the 
Assignments level. 


rate Cars; 


Shipper Car Orde 
| | | Pool Assignments Referenced by Movement Instructions 
Movement Instruct S; 


| Movement Instructions may also be used to redirect cars assigned to 

C y | | articular pools. This enables Central Car Control to temporarily with- 
draw all cars, or cars of a particular type, ownership, or class, and use 
them for other loading. 


Pool Assignments Other Than Commodity Pools 


entral Car Control makes assignments of cars to various custom 
agents, and commodities to best utilize appropriate equipment, pr 


customer requirements, and meet commodity demands. 
nighest priority 


mlabe > - p ^ Y q. v ` = m a m n. : : - 
iiike other Car D ril on order )iDSsO.ul L 


t a car is assigned offline, or in a national pool, it is reverse 

in the absence of other instructions. If the system is unable to 
a car to its offline assignment, Central Car Control is requested 
enter a Special Instruction to route the car to its assignment. 


procedure for applying 


ppiication override 








_ Cars assigned to MoPac pools (except commodity pools) that are not 
reierenced by Absolute Control Orders or Movement Instructions rank fifth 
in the Car Distribution priority system. Cars assigned to these MoPac 
pools are destined to their pool-assigned destinations regardless of 
their present billing. Empty cars moving toward their MoPac agent-pool 
assignments may be applied to Shipper Car Orders prior to their arrival. 
Cars assigned to specific customers are delivered to those customers upon 
their arrival if spotting instructions are present. If unapplied to 
Shipper Car Orders, agent pool cars assume Hold for Distribution status 
upon their arrival. 


2.2.6 Empty-Car Waybills 


| Some categories of cars require empty waybills to be input by the 
field. Primarily these are for national pool cars, privately-owned un- 
assigned cars, and maintenance-of-way cars. Except for the last group, 
reverse route data retained in the system to aid in billing the cars, but 
these may be overridden if the car is moving contrary to reverse route, 
based on the instructions of the owner-pool operator. 


PY PY, Absolute Control Orders 


Absolute Control Orders are orders issued by Central Car Control to 
control the movement of specific ownerships, series, or type of empty 
cars. If a car has not been applied to a Shipper Car Order via Absolute 
Application, has no existing Special Instruction, and is not a Pool Cat, 
1t is checked for an existing Absolute Control Order. 


Absolute Control Orders are used primarily to control the movement of 
empty cars in short supply. Being of high priority they are likely to be 
of a temporary nature, but can be made effective for specified lengths of 
time. Acceptance Absolute Contrci Orders may be entered that will allow 
empty cars received in interchange to be accepted, that would have other- 
wise been rejected. 


Cars are automatically applied to Absolute Control Orders upon the 
reporting of certain events. Absolute Control Orders may be placed in 
effect system-wide, in regions, zones, Customer Service Center areas, or 
at specific stations. Empty cars may be directed to online destinations, 
to specified roads at off-junctions, or to offline stations with routes 
designated. Once an empty car is applied to an Absolute Controi Order, 
its destination becomes absolute, and only Central Car Control can change 
its destination before the car reaches its final empty destination. 


A Central Car Control employee will indicate on each Absolute Control 
Order whether the cars reaching the empty destination will assume Hold 
tor Central Car Control status, Hold for Storage status, or searcn for 
other Car Distribution orders. Central Car Control (and some designated 
field forces) may apply these cars to Shipper Car Orders in that Customer 
Service Center responsibility area prior to their arrival. 





2.2.8 Shipper Car Orders 


Although ranked in priority following the Absolute Control Order in 
the Car Distribution priority system, Shipper Car Order input is limited 
to the Customer Service Center. When a MoPac customer requests one or 
more cars for loading, a Shipper Car Order is entered into the system by 


the Customer Service Center. 


Application of cars to Shipper Car Orders is a manual process and 
accomplished by Central Car Control and such field forces as may be 
designated by Central Car Control. 


Although Shipper Car Order Application is a manual process, the com- 
puter validates the application; it verifies that the Shipper Car Order 
requires the application of another car, it ensures that the car applied 
is in a location and status such that it is available for application, 
and it makes certain that the car applied meets the physical requirements 
of the order. 


PO Movement Instructions 


In the process of providing disposition for an empty car, the system 
continues to search through the orders and instructions. If the car has 
not been applied to a Shipper Car Order via Absolute Application, has no 
existing Special Instruction, is not a Pool car, and does not fit the 
parameters of an Absolute Control Order, it is checked for an existing 
Movement Instruction. 


Movement Instructions are issued to move specific numbers of empty 
cars of a certain ownership, series, or type, to various online supply or 
storage points, or to desigmated offline locations. Movement Instruc- 
tions can be made effective for specified periods of time, or the end 
date may be left open for standing types of orders. 


Cars are automatically applied to Movement Instructions upon the 
reporting of certain events. Like Absolute Control Orders, but of a 
lower priority, Movement Instructions may reference pool numbers, en- 
abling Central Car Control to override assignment or matrix destinations, 
diverting cars assigned to those pools to other loading, whether online 
or offline. 


Once an empty car is applied to a Movement Instruction and the status 
indicates that the car is moving, or is available to move, its desti- 
nation, too, becomes absolute, and only Central Car Control can change 
it. These cars may be applied to Shipper Car Orders at their final empty 
destination. 


Central Car Control will indicate on each Movement Instruction if the 
cars reaching the empty destination will assume Hold for Central Car Con- 
trol status, Hold for Storage status, or search for other Car Distri- 
bution orders. Central Car Control and designated field forces may appiy 


A YO mm 


these cars to Shipper Car Orders in that Customer Service Center respon 
sibility area prior to their arrival. 


«2.10 Commodity Pools 


Commodity Pools are MoPac assiznments of cars for the handling of 
specific commodities or types of loadings. These pools differ from 
regular pool assignments in that they have no specific location and are 
not assigned to specific shippers. 


Empty destinations for cars in Commodity Pools are provided by Pool 
Matrices. These matrices are created and maintained by Central Car Con- 
trol and provide empty online disposition for every commodity pool car as 
it is reported empty at any system location. 


Cars in Commodity Pools may be applied to Shipper Car Orders. Even 
after a car has been destined per its Pool Matrix, the use of the car 1s 
permissible for local orders if it is in a status acceptable for appli- 


cation. 


Commodity Pools rank immediately under Movement Instructions in the 
priority system. This priority can be raised by referencing the Commo- 
dity Pool Number with an Absolute Control Order or a Movement Instruc- 
tion. The series, type, owner, etc. may aiso be entered as a parameter 
on Absolute Control Orders or Movement Instructions to destine cars with- 
in a Commodity Pool on a desired priority to the Pooi Matrix destination 


or to an alternate destination. 


Commodity Pool cars arriving at their empty destination, not as yet 
applied to Shipper Car Orders, assume Hold for Distribution status. 


FP Permissive Control Orders 


In providing empty disposition, the final check that is made is for 
Permissive Control Orders.  Peraissive Control Orders are the lowest in 
priority of all orders. They are used to govern the disposition of sur- 
plus empty cars. They may direct foreign cars home, move cars to major 
distribution or storage points, or hold cars to protect future loadings. 


Once a system car is applied to a Permissive Control Order, its des- 
tination is permissive. That is, the destination can be changed at any 
intermediate setout point to be used on local orders. 


2.3 Data Base 


The principal files of the MoPac Car Distribution System are the Con- 
trol Order Files, Shipper Car Order Files, Pool Files, Speciai Instruc- 
tion Files, Home Route Files, and SCO 90/100 Files. 


The Control Order Files contain the Absolute Control Orders, Movement 
Instructions, and Permissive Control Orders. Each order may be defined 
by car type, owner, condition code, or pool. The orders contain effec- 
tive dates and the geographic regions in which they are applicable. Each 
order describes the proper disposition for each car to which it applies; 


that is, it specifies each car's destination and how to handle the car 
when it reaches that destination. 





The Shipper Car Order Files are arranged by Customer Service vet. 
Each Shipper Car Order on the file contains complete customer intor- 
mation, the type of car needed, the total number ot cars needed, the nun- 
ber needed per day, and how long the car order is to be uin ettect. In 
addition, each car order shows the number of cars already supplied to the 
order and the initial and number of each car applied. 


Although every Missouri Pacific system car belongs to either a Cus- 
tomer Pool, an Agent Pool, or a Commodity Pool, many of these pools are 
surplus disposition pools and hence need not be reportec to the AAR. an 
Pool Files describe these pools, each of which is identified by a pool 
identification number. Customer and Agent Pools contain fixed desti- 
nations for the cars comprising these pools. Commodity Pools have a 
matrix which provides destination information which is dependent on where 
the car becomes available. Cars that make up each pool are identified by 


initial and number. 


As previously mentioned, Snecial Instructions can destine a car to 
either an agent or a customer, online or offline. The Special Instruc- 
tions are stored in the Special Instructions File. Each Special Instruc- 
tion in the file contains the initial and number of each car affected by 
the instruction and the destination information for the cars. 


The Home Route Files contain information used to determine the dıs- 
position of foreign empty cars. These files contain such information as 
the identities of roads that make direct connections with MoPéc and the 
locations of these junctions, a list of roads that connect directly with 
each road that has a direct connection with MoPac, and information used 
to reverse-route foreign empties. The data in these files are thus used 
to determine the system destination of foreign empty cars to be delivered 


offline. 
The SCO 90/100 Files are used to: 


l. Determine MoPac's liability for accepting empty, general service, 
foreign cars in interchange; and : 


2 Expedite the returning home of these foreign cars. 


These Special Car Orders reflect AAR directives and apply oniy to 
certain car types; namely, SCO 90 applies to boxcars, and SCO 100 appiles 


to gondoias and ílatcars. 
2.4 Central Car Control Procedures 


The MoPac Car Distribution System provides Central Car Control per- 
sonnel with online, real-time procedures which permit them, via CRT, to: 


Le Create, maintain, and delete pools, orders, and instructions; 


2 Obtain information regarding existing pools, orders, and 
instructions; 


Je Obtain information on empty car movements, characteristics, and 
statuses. 


Brief descriptions of the procedures used by Central Car Control foilow. 


Pool Input-Inquiry 





Permits user to create, maintain, and delete pools; enables us 
obtain information about pools and the cars within them. 


Shipper Car Order Application Inquiry 





The normal procedure for applying cars to Shipper Car Orders; enables 
user to inquire on outstanding Shipper Car Orders and to determine the 


status of Shipper Car Orders. 


Abso.ute Application 





Used to assign highest priority application of a car to a Shipper Car 
Order; that is, override a normally prohibitive car characteristic or 
status (e.g., a car in Bad Order status). 


Special Instruction Input-Inquiry 





Used by Central Car Control to issue Special Instructions and obtain 
information concerning the status of specified Special Instructions. 


Absolute Control Order Input-Inquiry 





Used to input Absolute Control Orders and obtain information con- 
cerning the status of specific Absolute Control Orders. 


Movement Instructions Input-Inquiry 





Used to input Movement Instructions and obtain information regarding 
the status of specific Movement Instructions. 


Permissive Control Order Input-Inquiry 





Used to input Permissive Control Orders and obtain information con- 
cerning the status of specific Permissive Control Orders. 


Change Destination 





Permits the user to change the destination of empty cars moving on 
low-priority orders and instructions. 


General Inquiry 





Permits user to review empty cars received in interchange, released 
from industry, released from holds, and moving on trains. 


Car Supply Exception Input-Inquiry 





E 


Used to create and request Car Supply Exception Reports (or Central 
Car Control Management. 


Unsolicited Messages to Equipment Control 





Based on field reportings of daily activities, certain messages are 
sent to the Car Distributors as soon as the events are reported. These 
include the foilowing: 


Interchange Lists: Every interchange cut that is reported with empty 
cars produces an interchange list identifying delivering 
carrier, junction, time of interchange, and disposition of each 
car. These lists are a primary source of supply data for 
filling car orders. 


Customer Refusals: Whenever an empty car is refused at industry, a 
message to the Car Distributor notifies him of the time, place, 
and reason. He then can decide whether the car can be used 


elsewhere or must be sent to the cleaning-rip track. 


Changes in Car Grade: Whenever a new mechanical condition is reported 
for a car, the Car Distributor is notified for potential re- 
asSignment in a different pool. 


Sect ton j 


DSAI CAR DISTRIBUTION MODEL 
Description 


During the past fifteen years, Decision Systems Associates, Inc. 
(DSAI) has developed a set of extremely efficient mathematically optimal 
algorithms for solving transportation problems on a large scale com- 
puter. A simulation of the application of these algorithms to solve car 
distribution probiems was conducted on the Southern Pacific Railroad. 
These optimization algorithms have also had extensive use by large 
government agencies, including the U. S. Marine Corps. 


The transportation algorithms developed by DSAI can be used to cen- 
trally assign cars to car orders or to centrally distribute cars to agen- 
cies and then to assign cars locally to car orders. In either case, a 
transportation problem is generated in terms of the best estimates of 
both the available resources and the anticipated demands. Resources and 
demands are projected for an extended period of time. This time projec- 
tion is long enough to permit the algorithms to take cars released cn one 
day at one end of the ra'lroad and assign them to future demands at the 
extreme opposite end of the railroad. 


The algorithms solve the transportation proble:n through a series of 
Successive surface optimizations with each optimization constraining 
those that follow. Optimizations that can be made include the following: 


Minimize delay in meeting demands; 
Minimize the use of foreign cars; 
Minimize the amount of car type substitutions; 
Minimize the number of destination change orders; and 
Minimize empty-car costs. 

Additional objectives could be considered. 


The optimization model includes a unique nonlinear algortthm for 
determining the best distribution of cars to demands when Cars are in 
snort supply and some demands cannot be filled. The distribution 
algorithm accepts user-specified priorities for each car order and always 
enSures that high priority orders are filled before lower priority 
orders, while simultaneously ensuring that the maximum number of orders 
are filled. Among orders of equal priority, any car shortages are shared 
in accordance with user-specified proportionate or disproportionate dis- 
tribution policies. Use of the distribution algorithm guarantees that a 
feasible transportation problem is generated and that any car shortages 
have been optimally distributed in accordance with railroad policies. 
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The Shipper Order Application Report will describe the cars that have 
deen applied to or removed from Shipper Car Orders. The report will 
list, for each agency and each Shipper Car Order, the initial and number 
of the cars applied to or removed from the Shipper Car Order. 


The Daily Status Report will describe the projected demand and suppl 
for each agency represented in the model. For each agency, the report 
wili describe, by day, the number of empty cars demanded, the number of 
unfilled demands, and the number of cars required for buffer stock; also 
the number of empty cars on hand, the number projected to arrive, and the 
number projected for local release or receipt will be included in the 
report. 


3.3 Model Inputs 


The principal inputs to the DSAI model are the Dictionary data, 
empty-car demand data, empty car supply data, and empty car status data. 


Dictionary data are static data items that remain constant; that is, 
data values that do not change each time the model is executed. 
Dictionary data describe the physical system being modeled, the types of 
cars being distributed, and the rules for handling empty foreign cars. 


The Dictionary contains agency data such as the mame of the agency, 
the empty-car buffer requirements for the agency, substitute car types 
acceptable to the agency, and the rules for disposing of empty foreign 
cars that become available at the agency. 


The Dictionary also contains interagency data, including transit time 
between agencies, line mileage between agencies, and the next block 
breakup point at any agency for a car that is destined to any other 
agency. 


Various cost data are also included in the Dictionary, including 
initial switching costs, maintenance costs, the switching cost associated 
with changing the destination of a car, and train operating costs. 


Demand data for empty cars are of two types, projected demands and 
Shipper Car Orders. Projected demands Simply describe the number of cars 
of each car type or substitute car type expected to be needed each day by 
each agency. Shipper Car Orders describe the actual demands for empty 
cars at each agency. Each Shipper Car Order contains the number of cars 
ordered by type/substitute, the date needed, the number of cars already 
applied to the order, the initial and number of each car applied to the 
order, and the number of cars yet outstanding on the order. 


The supply data for the model describe the number of empty cars pro- 
jected to become available at each agency location for each day. The 
projected number is given for each car type, each ownership, and each 
event that makes the car available (i.e., release events and interchange 
receipt events). In the present simulation model, future supply data is 
projected based upon release/receipt histories and projected empty 
release dates for currently loaded cars on-line. Where detailed loaded- 
car data are available, the model will also consider per diem and mileage 
rates in the assignment of foreign cars. 


Empty car status data contain current information on the location, 


destination, and status of online system and foreign empties. 


Hardware-Software 


The DSAI model is programmed in CDC's FORTRAN Extended language and 
1S currently operational on a CDC CYBER 175 computer utilizing the SCOPE 
3.4 operating system. With minor modification, the model could be made 
operational on any CDC CYBER 17X of 6X00 model computer operating under 
SCOPE 3.4, NOS 1.0, or NOS/BE 1.0 provided the following conditions are 


met: 


300,000 (base 8) words of central memory must be available for 
program use; and 


Up to 300,000 words of random access peripheral storage must be 
available for program use. 


Section 4 


ENHANCED CAR DISTRIBUTION SYSTEM 
Overview 


The Mıssouri Pacific enhanced Car Distribution System will be the 
Same as the existing Car Distribution System, except in the treatment of 
empty gondolas. The distribution of gondolas and their application to 
Shipper Car Orders will be optimized by the use of the DSAI model. This 
section of the document addresses the enhancements to the existing Car 
Distribution System; that is, it deals only with the disposition of empty 
gondolas through the use of the DSAI model. 


The DSAT model will be executed daily to distribute empty gondolas 
and to assign them to Shipper Car Orders. Figure 4-l shows the four 
ma jor aspects to the use of the DSAI model, namely: 


l. Collection and preparation of the static data base, 

2. Preparation and transmission of the dynamic data base, 
Execution of the DSAI model, and 
Review and implementation of model output. 
these aspects is briefly described in the following paragraphs. 


collection and preparation of the static data base 1S, for the 
most part, a one-time activity. This activity builds static model infor- 
mation which are used by the model each time it executes and which does 
not change each time the model executes. The static data base consists 
Of car ownership data, agency data, and inter-agency data. In the con- 
text of using the DSAI model to distribute gondolas, the term agency is 
synonymous to a Missouri Pacific Transportation Control System reporting 
location. Once developed, this data base is placed on a file referred to 
as the Dictionary. Figure 4-2 identifies the components ct this data 
base and the process of develcping it. 


The preparation and transmission of the dynamic data base occurs 
daily. The dynamic data base contains daté which changes from day to 
day. This data base contains projected estimates of the Supply and de- 
mand for empty gondolas, the current status of Shipper Car Orders, and 
the current status and location of empty gondolas throughout the MoPac 
System. Figure 4-3 identifies the components of the dynamic data base 
and the activities involved in developing it. 


Although this feasibility study is primarily concerned with the dail; 
execution of the DSAI model, the model will also be executed on a monthiy 
basis. The monthly executions will be made without using the Shipper Car 
Order Application/Deletion feature. The output from the monthly execu- 
tions will show the forecast supply of and demand for empty gondolas by 
agency for the entire upcoming month. This report will be used by Cen- 
tral Car Control management for long-range planning purposes. 
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The DSAI model is executed daily using the static and dynamic data 
bases. Given the supply and demand for empty gondolas, the current 
status and location of these empties throughout the system, and the time 
and cost involved in moving them from any given system location to any 
other system location, the DSAI model determines the optimum assignment 
of destinations to cars and application of cars to Shipper Car Orders. 
The primary outputs of the model are Origin-Destination Flow Orders, 
Shipper Car Order Applications and Deletions, and Destination Change 
Orders. 


The DSAI model outputs are transmitted to the MoPac computer, stored 
on a Model Output File, reviewed, and implemented. This process is 
depicted graphically in Figure 4-4 and discussed in the following para- 
grapns. 


The Origin-Destination Flow Orders are grouped according to desti- 
nation and matched with existing Absolute Control Orders having the same 
destination. Differences between the Origin-Destination Flow Orders and 
the existing Absolute Control Orders are identified and the Absolute Con- 
trol Orders are updated. In some cases, new Absolute Control Orders are 
created. An Absolute Control Order report is generated which displays 
for the Car Distributor the Absolute Control Orders to be in efíect for 
the next seven days. The Car Distributor can manually change any of the 
new Absolute Control Orders. 


Cars specified by the model to be applied to or deleted from Shipper 
Car Orders are automatically applied and/or deleted. A Shipper Car Order 
report is generated for Central Car Control which displays the identities 
of the cars applied to and deleted from each Shipper Car Order; the 
report also shows the current status of each Shipper Car Order. Central 
Car Control can manually modify any of these applications or deletions. 


Cars whose destinations the model determined should be changed are 
listed on a Destination Change Order Report along with their current 
location, current destination, and new destination. These destination 
changes are then manually input. Each car whose destination is changed 
is removed from an existing Absolute Control Order and applied to a 
different (perhaps new) Absolute Control Order. 


A Daily Status Report is also generated. This report shows, by 
agency, the expected number of empties to be demanded and supplied, and 
how they are to be flowed for the next six days. 


A Car Assignment Switch is also used to control the implementation ct 
the model output. When this switch is ON, the enhanced Car Distribution 
System will perform Shipper Car Order Applications and Deletions as 
indicated by the DSAI model, and the related reports will ve producec. 
When this switch is OFF, no Shipper Car Order processing is accomplishec. 
The remaining documentation in this section treats the switch as being ON. 
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Figure 4-2. Model Output Implementation 


Hardware 







án overview of the hardware configuration for the enhanced Car Dis- 
tribution System is indicated in Figure 4-1. All processing required to 
develop the static and dynamic data bases will be accomplished on IBM 
3033 hardware located at MoPac system headquarters in St. Louis. 


Execution of the DSAI model will be on a CDC CYBER 175 system also 
located in St. Louis, Missouri. 


Implementation of the model output and model output report generation 
u wıll also be performed using the IBM 3033 hardware at MoPac headquarters. 


Communications between the IBM 3033 hardware in St. Louis and the CDC 
hardware will be via normal voice-grade telephone lines. 







4.3 Operating Scenario 





The normal sequence of daily activity involved in using the DSAI 
model to dıstribute gondolas and apply them to Shipper Car Orders is out- 
lined in Figure 4-5 and described in the following: 


la The first step is to update the system-generated forecasts of 
demands for empty gondolas for the next seven days. To deter- 
mine whether or not the system-generated forecasts need to be 
updated, the Car Distributor will use Shipper Car Order status 
reports, Shipper Car Order history reports, and the model- 
generated daily status report; he will communicate with Customer 
Service Centers; and he will use his own experience and judgment. 
The Car Distributor calls up a formatted CRT screen and 
enters these data. This activity will be accomplished prior to 

the end of the second trick each day. 


The next step 1S to update the system-generated forecasts of 
Supplies of empty gondolas for the next seven days. As is the 
case with updating demand forecasts, the Car Distributor will 
utiiize various sources of information. He will use reports 
describing the history of Interchange Receipts, Hold Releases 
and Industry Releases; he will review loaded placements at 
industry; he will -communicate with Customer Service Centers; and 
he will use his own experience and judgment. 

The Car Distributor calls up a formatted CRT screen and 
enters these data. This activity will also be accomplished 
prior to the end of the second trick each day. 


The system then compietes the construction of the dynamic data 
base by extracting and formatting current Shipper Car Order 
information and extracting and formatting the current status and 
location of empty, online gondolas. 


Following its construction, the dynamic data base is transmitted 
to the CDC installation. 
executed. 


The DSAI model is then 
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5. DSAI MODEL EXECUTED ON CDC 6600 7:30 PM 
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Figure 4-5. Daily Operating Scenario 
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Section 5 


MISSOURI PACIFIC SYSTEM-DSAI MODEL INTERFACE 


5.1 Description 


The interface between the Missouri Pacific Car Distribution System 


and the DSAI model refers to the following: 


l. The interface between the Car Distributor and the enhanced Car 
Distribution System. This interface consists of the computer- 
generated reports reviewed by the Car Distributor and the CRT 
inputs to the system made by the Car Distributor. 


The interface between the MoPac System and the DSAI model. This 
interface consists of the static data base (dictionary), the 


dynamic data base, and the Model Output File. 


The software required to support the above two interfaces. This 
software refers to the programs which create the reports, read 
the CRT inputs, create the static and dynamic data bases, and 
implement the model results which are stored on the Model Output 


File. 


3.2 Reports 


There are six reports made available to the Car Distributor for each 
execution of the DSAI model. Two of the reports, the Shipper Car Order 
Demand History Report and the Empty Car Supply History Report, are 
printed prior to execution of the model to assist the Car Distributor in 


the development of the dynamic data base. 


Four reports are made available to the Car Distributor following 
execution of the model. They are: 


Absolute Ccntrol Order Report, 
Daily Projected Status Report, 
Manual Destination Change Order Report, and 
Shipper Car Order Report. 
A brief description of each report follows. 


5.2.1 Shipper Car Order Demand History Report 


The Shipper Car Order Demand History Report describes the history of 
shipper demands for empty gondolas for the previous months. 


For each day of the week, for each agency, and for each shipper with- 
in each agency, the report lists the mean and maximum number of empty 


gondolas ordered, by type of gondola. The report also shows the sum of 
the demands for all shippers within each agency, giving an agency-by- 


agency total. 


This report is used by the Car Distributor to help him determine if 
any changes need to be made to the system-generated projected demands for 
empty gondolas for the next seven days. 


dok Empty Car Supply History Report 


The Empty Car Supply History Report describes how and how many oi 
each type of empty gondola historically became available at each agency. 


The report lists, for each day of the week and for each agency, the 
mean and maximum number of empty gondolas received in interchange from 
each connecting road, the mean and maximum number released from each type 
of hoid, and the mean and maximum number released from each customer 
within each agency. The report also gives totals for each agency, by 
showing the sum of all types of events making empties available. 


This report is used by the Car Distributor to help him determine if 
any changes need to be made to the system-generated projected supply of 
empty gondolas. 


5.2.3 Absolute Control Order Report 


1`e Absolute Control Order Report is a printout of the current status 
oí ever ' Absolute Control Order against gondolas. 


For each Absolute Control Order, the report lists such information as 
the effective dates of the orders, where the orders are effective, the 
car kind and ownership involved, the disposition of the cars, and the 
number of cars ordered, either total or per day. The report also indi- 
cates the difference between the number of cars ordered on the current 
Absolute Control Orders and on the previous day's Absolute Control Orders. 


The purpose of this report is to keep the Car Distributor aware of 
the day-to-day changes in Absolute Control Orders resulting from each run 
of the DSAI model. 


5.2.4 Daily Projected Status Report 


The Daily Projected Status Report presents estimates of the daiiy 
supply, demand, and balance of empty gondolas for each demand agency. 


The projections shown in the report are for the next seven days. 
These projections estimate the kind and number of empty gondolas needed 
and the kind and number to be available, either locally through Inter- 
change Receipts and Industry/Hold Releases, or to arrive from other agen- 
cies. The report also shows the number of empties required for buffer 
stock, and the difference between the number of empties required and the 


number to be available. 


The purpose of this report is to alert the Car Distributor to 
Shortages that are projected to arise, and thereby permit him to take 
action on such situations. 


tral Car Control management for long-range planning purposes. 


5.2.5 Manual Destination Change Order Report 


The Manual Destination Change Order Report is a listing of cars that 
are to have their destinations changed by the Car Distributor. 


This report shows the type and quantity of cars to have their desti- 
nations changed, the current destinations for these cars, their new des- 
tinations, and their current location or train. 


The purpose of this report is to re-direct cars as a result of 
running the DSAI model with more accurate estimates of empty car supply 
and demand. 


5.2.6 Shipper Car Order Report 


The Shipper Car Order Report gives the current status of Shipper Car 
Orders after the most recent car applications or deletions. 


For each shipper, the report shows the car kind requested, the start 
date of the order, the number of cars required daily, the number of cars 
automatically applied today, the number automatically deleted today, the 
total number ordered, the total number applied, and the net demand. 


The report also lists the initial and number of each car automa- 
tically applied or deleted that day. 


23.3 Procedures 


Three new procedures are required to support the enhanced Missouri 
Pacific Car Distribution System. These procedures are as follows: 


Le Update Car Demand. This procedure permits the Car Distributor 
to revise the estimate of the projected demand for empty gon- 
dolas for the next seven days. The demand estimates are input 
via CRT using formatted screens. This procedure may be used 
each day prior to execution of the DSAI model. 


Update Car Supply. This procedure permits the Car Distributor 
to revise the estimate of the projected supply of empty gondolas 
for the next seven days. As with the Update Car Demand proce- 
dure, the Update Car Supply procedure utilizes formatted CRT 
screens and may be used each day during development of the DSAI 
model dynamic data base. 


Set Car Assignment Mode. This procedure enables the Car Distri- 
butor to specify whether or not the enhanced Car Distribution 
System is to automatically apply cars to or delete cars from 
Shipper Car Orders. When the Car Distributor sets the model to 
ON, the system applies or deletes cars; when the Car Assignment 
Mode is set to OFF, no application or deletion is made. The 
default mode is ON. When the Car Distributor inputs the Car 
Assignment Mode, he may specify that the particular mode is to 
be in effect only for that day, he may specify a range of days 
for which it is to be in effect, or he may specify that it is to 
be in effect indefinitely. 


5.4 Data Base 


There are three distinct data bases which act as interfaces between 
the Missouri Pacific Car Distribution System and the DSAI model. These 
data bases are the static data base, the dynamic data base, and the Model 
Output File. 


2.4.1 Static Data Base 

The static data base, or dictionary, contains the constants of the 
system. This data base contains car ownership data, agency (or reporting 
location) data, and inter-agency data. The items of this data base are 
briefly described in the following. 


A. Car Ownership Data 


Car Initials Table. Contains car initials, car ownership group, 
and car ownership initials of cars to be distributed. 





Car Type Table. Contains car kind and car type for each kind of 
Car to be distributed. 





AAR Car Service Zones. Identifies the AAR Car Service Zones 
each car ownership operates in. 





Legal Foreign Loadings. Identifies what ownerships may be 
applied to car orders in the AAR zones. 





Agency Data 


Agency Identification Table. Contains the name of each agency. 





Preferred Ownership Identifier. Specifies which ownership is 
preferred at each agency. 





Car Type Substitution Table. Describes the acceptable substi- 
tution car types at each agency and the level of desirability of 
each substitution type. 





Buffer Constants Table. Describes the maximum and minimum 
buffer requirements at each agency and the total storage capa- 
city of each agency. 





Agency AAR Car Service Zone.  Identifies the AAR Car Service 
Zone each agency 1s located in. 





Back-Hauling Policy Table. For each agency, this table 
describes the agencies that may be shipped to or from for each 
ownership. 





Inter-Agency Data 


Transit Time Table. Specifies the median transit time from each 
agency to all other agencies. 








Transshipment Mileage Table. Specifies the transshipment 
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mileage from each agency to all other agencies. 





Next Block Break-Up Agency Table. Specifies the next block 
break-up agency for cars moving from each agency to any other 





agency. 


Cost Data. Contains initial switching cost, maintenance cost 
per mile, destination change switching cost, and train cost per 
mile. 





5.4.2 Dynamic Data Base 


The dynamic data base contains the variables of the system; that 1S; 
data whose values may change from day to day. The dynamic data base con- 
sists of the following data items. 


Agency Demand Estimates. Contains the estimated demands for 
empty gondolas for each agency for each of the next seven days. 





Agency Supply Estimates. Contains the estimated supply of empty 
gondolas at each agency for each of the next seven days. 





Car Assignment Mode. Indicates whether or not cars are to be 
automatically applied to or deleted from Shipper Car Orders. 





Shipper Car Order Status. For each Shipper Car Order, identi- 
fies the kind of car needed, the number needed, the dates 
needed, «cceptable substitute car kinds, how long the order is 
in effect, and the initial and numbe. of each car currentiy 


applied to the order. 





Car Status and Location. Gives the status and location of every 
empty gondola on the Missouri Pacific System. 





5.4.3 Model Output File 


The Model Output File contains the following types of data. 


Daily Projected Status. Contains the estimated supply ot, 
demand for, and inter-agency flows of empty gondolas for each 
agency for che next seven days. 





Shipper Car Order Applications or Deletions. For each Shipper 
Car Order, identifies by initial and number the cars to be 
applied to or deleted or both from the Shipper Car Order. 





Destination Change Orders. The Destination Change Orders 
describe, by car kind and number, the cars to have their desti- 
nations changed. These orders describe the current destinations 
of these cars, their new destinations, and their current loca- 





tion or train. 





3.2 Interface Software 

The software required to support the Missouri Pacific Car Distri- 
bution System/DSAI model interface consists of the programs used to ac- 
complish the following: 

A. Data Base Development, 

Model Output Implementation, and 

C. Report Generation 
In the following paragraphs, each program module is identified along with 
the estimated costs in programmer or analyst man-weeks and IBM 3033 
Computer time in minutes required to develop the module. 


3.2.1 Static Data Base Development Software 


These modules create the car ownership data, agency data, and inter- 
agency data. 


A. Car Ownership Data Development Modules 





IBM 3033 
MODULE MAN-WEEKS COMPUTER TIME 








Create Car Initials Table 
Create Car Type Table 


Create AAR Car Service 
Zones Data 


Create Legal Foreign 
Loadings Data 


Total Estimated Costs 


Agency Data Development Modules 





IBM 3033 
MODULE MAN-WEEKS COMPUTER TIME 








Create Agency Identification 
Table 


Create Preferred Ownership 
Identifier 


Create Car Type Substitution 
Table 


Create Buffer Constants Table 





Create Agency AAR Car 
Service Zone Data 


Create Back-Hauling 
Policy Table 


Total Estimated Costs 


Inter-Agency Data Development Modules 





IBM 3033 
MODULE MAN-WEEKS COMPUTER TIME 











Create Transit Time Table 5 250 


Create Transshipment 


Mileage Table 30 


Create Next Block Break-up 


Agency Table 50 


Create Cost Data 





Total Estimated Costs 12 
Dynamic Data Base Development Software 


These modules create the data for the model dynamic data base. 


IBM 3033 
MODULE MAN-WEEKS COMPUTER TIME 











Forecast Supply and Demand 


and Car Record Data 800 


Record Car Distributor 
Modifications to Supply and 

Demand Forecast; Set Car 

Assignment Mode 4 





Total Estimated Costs 20 


Does Model Output Implementation Software 


These modules implement the output of the DSAI model, which is stored 
on the Model Output File. 


IBM 3033 


MODULE COMPUTER TIME 











Sort,Merge,Update 


Absolute Control Orders 800 


Apply or Delete Shipper 
Car Orders 





Format Destination Change Orders 
for Review by Car Distributor 


Total Estimated Costs 
Report Generation Software 


These modules generate the reports used by the Car Distributor. 


IBM 3033 
MAN-WEEKS COMPUTER TIME 





MODULE 








Generate Shipper Car Order 


Demand History Report 50 


Generate Empty Car Supply 


History Report 50 


Generate Absolute Control 
Order Report 


Generate Daily Status 
Report 


Generate Manual Destination 
Change Order Report 


Generate Shipper Car Order 
Report 


Totai Estimated Costs 


dodo) Software Development Cost 


The total estimated direct cost to develop the interface software is 
the sum of the estimated module development costs plus the estimated 
integrated testing and functional testing costs. These estimated costs 


are as follows. 


IBM 3033 
COST ITEM MAN-WEEKS COMPUTER TIME 











1. Module Development 
Static Data Base 
Dynamic Data Base 


Model Output Implemen- 
tation 


Report Generation 


Integrated Testing 


400 





3. Functional Testing 
Total Estimated Costs 6000 


The values of 10 man-weeks and 6000 computer minutes are estimates of 
direct costs, and do not include costs related to supervision, overhead, 
travel, general and administrative, and other miscellaneous costs. 





Section 6 


PROJECT IMPLEMENTATION 
6.1 Introduction 


This section outlines and describes the MoPac tasks required to 
effect a pilot implementation of the enhanced Car Distribution System on 
Missouri Pacific property. In addition to the task descriptions, esti- 
mates of MoPac programmer-analyst and management man-weeks and computer 
minutes required for each task are included. 


Section 6.2 briefly describes the tasks. Section 6.3 summarizes the 
estimates of direct project costs to MoPac. Figure 6-1 follows Section 
6.3 and contains an implementation schedule and the estimated manpower 
and computer requirements for each task. 


6.2 Project Tasks 


Following are high-level descriptions of the Missouri Pacific tasks 
to be performed in developing and implementing the enhanced Car Distri- 
bution System. | 


6.2.1 Project Work Plan 


The project work plan will describe in detail the specific tasks 
required to implement successfully the enhanced Car Distribution System 
in a pilot mode on the Missouri Pacific Railroad. Included in this docu- 
ment will be task descriptions, PERT charts, procedures, project manage- 
ment controls, and budget planning. This detailed work plan will be used 
by all project personnel as a guideline for task accomplishment. It will 
also be the basis for monthly progr ss reviews. 


6.2.2 System Functional Requirements 


The on-line, operational enhanced Car Distribution capability will be 
functionally described in a system requirements document. The primary 
intent of this document is to address the problem and solution to opt imum 
car distribution from a logical and functional point of view as opposed 
to a program design description. This document will be written primarily 
for railroad management and operating personnel. This specification wili 
be the basis for the system design of the interface software development. 


6.2.3 System Performance Measurement 


Car Distribution System performance measures will be defined and 
documented. The measurements are to be made both before and after the 
enhanced system is implemented. These before- and after- measurements 
will be equated and correlated with the levels of traffic and demand for 
empty equipment prevailing during the periods measured. These measure- 
ments will be used to assess the effectiveness of the enhanced Car Dis- 
tribution System. 
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Data Collection System Implementation 






































to the creation of the static data base 
he daily execution of the enhanced Car Distribution System. 


the enhanced Car Distrıbution System, vstem Impl=mentation refers 


data collection and development effort must be undertaken in support of 
tne development of the static data base. 
and developed include: 





Prior to 


implementation of 2345 6 7 8 9 | 
Project Work Plan i | 












The data items to be collected 






System Functional 
Requirements 


1S primarily a one-time operation, 
may be modiíied and updated from time 
inputting the manuaily 


Creation of the static data base 
the data base 
Creation of the data base consists basically of 


collected and developed data and creating the model dictionary. 

































to be distributed 





Car and owner initials of cars 


BÀ 
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System Performance 
Measurement 





Kind and type of car to be distributed 





FUNCTIONAL 
REQUIREMENTS 





Distribution System 
report generation, application of the Car Distributor procedures, 
mission of data to and from the CDC computer installation, implementation 
of the model output, and system maintenance. 
computer and programmer-analyst cost to MoPac to operate the system is 
include the cost of executing the 


enhanced Car 
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Agency AAR Car Service Zone information 
Final Report 
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Back-hauling policies 
















Procedures Application 
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task includes manual data collection and the development 
testing of software described in Paragraph 5.5.1. 
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Program Development 















This task refers to the software development described in Paragraphs Project Final Report 


This development effort 
code, test, and documentation of the individual modules. 









and 5.5.4. includes the design, 












The primary purpose of the final report is to recap and summarize the 
entire enhanced Car Distribution Project. 
accomplishments, 
future deveiopments. 

developments 
Distribution System. 













design ob- 
anc any recommendations 
The section of the report addressing future 
a foundation 


This will 






resources expended, 






Integrated Testing jectives, 


























Integrated Testing refers to executing the MoPac-developed modules as future work 


The estimated cost to complete this task is 
12 programmer-analyst man-weeks and 600 minutes of IBM 3033 computer time. 


a single, integrated system. 

















results of the system performance measurements. 






Functional Testing 

















Project Cost 





Functional Testing refers to executing the MoPac-developed software 
and DSAI model in a real-time, parallel mode of operation. 
cost of this task is 8 programmer-analyst manweeks and 400 minutes of IBM 
3033 computer time. 











The estimated 










implementation 
estimated 


time required for a pilot 
Distribution System 
in man-weeks and IBM computer minutes 

The 78 System Implementation management man-weeks 
52 man-weeks for a Car Distribution Supervisor of Equipment. 








26 months. 





enhanced Car 
direct costs 
marized below. 






to MoPac 










agency total. 
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In estimating development costs, it was generally assumed that a 
majority of the data processing and data base maintenance tasks required 
to develop interface data would be performed by the Missouri Pacific on 
its IBM computers. Specifically, the following assumptions were made: 
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DEVELOPMENT AND IMPLEMENTATION OF AN OPERATIONAL CAR ASSIGNMENT MODEL CAM Hierarchy Schematic 







A Introduction 

















































































6 6 As previously indicated, the current version of the Car Assiznment (1) Location, —_— were. and car ownership data contained in all 
Model (CAM) is imbedded in the simulation system developed under FRA interface records will be recorded in terms of model codes, 
contract number DOT-FR-65140. To utilize the model for Missouri Pacific L.e., agency numbers, model car-type codes, and model ownership 
assignments, the CAM must be removed from the simulator and incorporated group codes. 

13 13 into an operational System capable of interfacing the model with the " A i ' CAM ] 
Missouri Pacific car distribution system. Additionally, some modifi- (2) No data bases other than the model static data base will be Executive 
cation of the CAM itself will be required to provide new features such as maintained on the CDC computer system. 
assignments by car number and car order number and an optional strategic 

7 - run mode. : 











: (3) Modification of the current model static data base and maiate- 
nance programs will consist primarily of the removal of obsolete 
data base tables and maintenance code not needed by the opera- 


























The following sections outline and describe the tasks required to 














































































































































































































































develop and implement an operational CAM system on a CDC 175 computer tional system. 4 
=: M 1500 capable of interfacing with the enhanced Missouri Pacific car distri- : | = - 
bution system. In addition to task description, estimates in man-weeks 7.4 Program development | 
of DSAI personnel requirements and CDC 175 computer time in System l l | | Generate Er. Generate Prepare 
70 16 3500 Billing Units (SBUs) have been provided (one SBU equals $0.14 to $.028 Figure 7.1 schematically represents the hierarchy of the highest Demands Supply & Matrix Outputs 
depending upon turnaround requirements). level modules in the proposed operational CAM. The static data base Demand 
Maintenance program is not indicated in this schematic as it is an inde- 
1 12 6 600 Sections 7.2 and 7.3 provide a development overview and describe the pendent program whose only connection to the CAM is the data base itself. 
assumptions on which cost estimates were based. Sections 7.4 and 7.5 The subsections below outline the tasks associated with the development 
| discuss specific program modules to be developed and provide cost esti- of each of these modules and provide estimates of their development 
HH 8 7 400 mates for their development. Sections 7.6 and 7.7 describe other imple- costs. Development costs include the design, programming, testing, and 
mentation tasks and estimate total project costs. documentation of each module. 2 4 6 
Generate Generate Allocate 
bo : ' 89 78 7710 7.2 Development Overview 7.4.1 CAM Executive Supplies Problem 
上 一 - 13 13 The development of a CAM system suitable for implementation on an Development of an operational CAM system requires the development of 
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operational basis involves the following high-levei programming tasks: 





a new set of executive routines to control overall system functions. 
Functionally, the executive routines must: 


211 162 13710 











(1) The development of new executive routines to control the opera- 
tional system functions. 
















O perform system initialization and other houskeeping tasks. 























(2) The development of input modules capable of converting Missouri 


Pacific car supply and car order interface data to a form usable - 
by the CAM. 


O control tne execution of all other modules in accordance with 
- the mode of the CAM run; i.e., strategic assignment mode, no car 
assignment mode, or full assignment mode. 








-1. PROJECT SCHEDULE 


51 


















(3) The installation of the CAM matrix generators, allocators, and 


To ensure that the operational system will meet its functional 
static data base drivers into the operational system. 


requirements, the design of the executive routines will encompass much 
more than its own program functions. In particular, design of the exe- 
cutive routines will involve the following tasks: 




















(4) The development of output modules capable of converting tne 


optimal assignments produced by the CAM to a form usable by the 
enhanced Missouri Pacific car distribution system. 















O A detailed specification of the system control and problem data 
interfaces. 







(5) Modification of static data base maintenance programs. 
















O A detailed specification of the interfaces between all other CAM 


Completion of the above tasks will involve the development of a number of modules. 


program modules. In Section 7.4, each program module to be developed 1s 
identified and its relationship to existing code is outlined. Section 
7.5 provides estimated development costs for these programs. 
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A detailed specification of the functions to be performed by 
other CAM modules. 


Tne expansion of the logic of lower level modules in sufficient 
detail to ensure that all system functional requirements can be 
met and properly controlled by the executive. 


The development of the CAM executive will produce two products: 


(1) The executive routine programs, and 


The design document conteining hierarchy charts and detailed 
interface and functional descriptions which will form the bases 
for the design and documentation of lower level modules. 


P T*. Generate Demand Module 


The function of the demand generation module is to convert car order 
and car distributor demand interface records into internal demand records 
processable by the CAM. The information content of the internal demand 
record is displayed in Figure 7.2. The internal demand record coliects 
all assignment-relevant information about a demand or car order into a 
single record to be used by other modules. 


Subprogrars of this module establish specific ownership and eligible 
car type constraints for each demand utilizing assignment policy para- 
meters from the model static data base. Logic for developing the demand 
record will differ depending upon whether a car order interface record or 
a car distributor estimated demand interface record is used as the source 


of the demand record. 


Most programs in this module will represent new code that wiil depend 
upon the definition of the interface records. 


7.4.3 Generate Supplies Module 


The function of this module is to convert supply interface data into 
internal supply records. The information content of the internal supply 
record is displayed in Figure 7.3. The internal supply record coilects 
all assignment-relevant information for each on-line or future supply 
into a single record for use by other modules. 


Subprograms of this module establish the car characteristics needed 
to determine the eligibility and costs associated with car assignment. 
Logic for determiniag these characteristics will differ depending upon 
whether an on-line car interface record or a car distributor estimated 
release interface record is used as the source of the supply record. 

As was the case for the demand generation module, most of the pro- 
grams in this module will represent a new code that will depend upon the 
definition of the supply interface records. 


The four data items marked with an asterisk in Figure 7.3 
data items that can be generated by the CAM, but may also be 
available from the Missouri Pacific car distribution system. 


Figure 7.2 


Required Internal Demand Data 


Priority of the demand 

Demand agency 

Relative date car wanted 

Car type requested 

List of other car types eligible for assignment 


List of model owners eligible for this demand--the eligible owners list 
is prepared based upon routing data and destination AAR zone of the load, 


if available. 


Type of demand (car order if future estimate) 


Order identifier 


Number of cars required, 





Figure 7.3 


Required Internal Supply Data 


Destination agency 
Estimated arrival date at destination 
Owner of car(s) 


Car type 


Next available agency--specifies the next agency at which this car may 
receive a new empty assignment 


Projected availability date (0-15)--specifies the relative date on which 


the car will be available for a new empty assignment at its next available 


agency 
Optimum return agency (foreign cars only) 


Storage/return flag: indicates a foreign car enroute home or a system car 
enroute to or in storage 


Source code: indicates cor is empty enroute, in storage, or type of 
estimated release 


Per diem rate for car 
Mileage rate for car 
INumber of cars 


Car identifier, 


ee section 7.4.3. 





The first three items (next available agency, day, and arrival date 
at destination) represent car scheduling information. They can be esti- 
mated in the CAM using the model block break-up point and transit time 
tables in conjunction with the last reported location data in interface 
records. Although computation of these estimates is not difficult, 
better estimates, based on actual car routings and train schedules, may 
be available from the Missouri Pacific data bases. If such data are 
available, they should be provided to improve the accuracy of the CAM 
assignments. 


The fourth asterisked item, the optimum agency at which to return a 
foreign car, is a difficult and expensive data item for the CAM to 
generate. Computation of the optimum return agency for a foreign car 
requires that switch service flags, delivering carrier, and home route 
agency be specified in interface records and that the model optimum gate- 
way and prohibited reverse route tables be specified on the model static 
data base. 


Logic for estimating the optimum return agency for foreign general 
service flatcars in accordance with 1976 car service rules is currently 
contained in the simulation model utility processor. However, the appli- 
cability of this logic to gondolas on the Missouri Pacific 1S not known. 


In estimating the cost of developing the supply module, an estimate 
of eight man-weeks was attributed to the development of the optimum home 
route code. If the Missouri Pacific can provide a return agency directly 
in interface records, the cost estimate given in Section 7.5 for de- 
veloping the supply generator can be reduced by eight man-weeks and a 
considerable amount of data can be eliminated from supply interface 
records and the CAM staiic data base. 


7.4.4 Merge Supply and Demand Module 
The function of this module is threefold: 


(1) Demand records representing car orders are compared to the 
Supply records of cars that have been previously assigned to the 
order. On the basis of the assignment criteria contained in 
each record and run mode parameters, previous assignments are 
either rejected or retained, and the car order quote is adjusted 
accordingly. 


Unassigned car records destined to an agency are compared to the 
future demand requirements for the agency. Car records destined 
to an agency that match perfectly with a future demand require- 
ment at the agency are "prematched" and both the supply and de- 
mand record are removed from the problem. Strictly speaking, 
the prematch process is not required; nowever, it reduced model 
run costs significantly in the simulation model. 


Supply and demand records with identical assignment-relevant 
characteristics are merged to reduce problem size. Separate 
files detailing the mapping of car identifiers and car order 
identifiers into the compressed record are generated for later 
use in preparing model outputs. 


Some of the logic and program code for this module can be copied from 
existing CAM modules in the simulator. However, new record sizes, output 
requirements, and run mode features are required in the operational CAM 
so that much of the program code must be developed based on a new design 


of this module. 
Po Generate Problem Module 


The function of the problem generator is to reformat and organize the 
assignment data contained in the final supply and demand records into the 
various arrays and vectors required by the matrix generator and allo- 
cators. A fleet-sizing module within the problem generator completes the 
internal transportation problem by generating slack demands and adjusting 
agency buffer requirements in accordance with expected fleet size re- 


quirements. 


Some of the logic and output requirements for the problem generation 
module ar? already defined in the current simulation model. Modifi- 
cations in design will be required due to differences in input; however, 
development of the problem generation module will exploit, as far as 
possible, existing routines. 


7.4.6 Matrix Generator and Allocation Modules 


The function of the matrix generator and allocation modules of the 
CAM is to solve, optimally, the transportation problem generated. 


Incorporation of the existing program code for these modules is 
expected to require minimal effort. Revisions to the matrix generator 
will be required, however, to make assignments in strategic run mode. 
These modules form the heart of the CAM and as such will be incorporated 
directly into the operational model. 


1.4.7 Prepare Outputs Module 


The function of this module is to decode the assignment vectors pro- 
duced by the allocation module and format these assignments into the 
various interface output records to be produced by the model. 


Producing model interface outputs may be divided into three program 
Subtasks: 


(1) Merging the highly  abstracted  allocator assignments with 
previously developed files to produce a file of assignments con- 
taining car and car order characterisitics data. 


Processing the new assignment file to identify the type of 
assignment (e.g., destination change, car order match, etc.) to 
produce the appropriate interface records, 


Forecasting arrival times for cars with new assignments and pro- 
ducing the daily status report outputs. 





















Very little of the code in the existing CAM output processors is 
expected to be salvageable for use in the operational model. The de- 
coding and routing of CAM allocator assignments is a relatively complex 
data processing task that is highly dependent upon the format and data 
content of interface files. Records passed between the current simulator 
and the CAM will bear little resemblance to those utilized in the opera- 
tional model. Therefore, the programs in the output module will require 
redesign and reprogramming. 


7.4.8 Modification of Static Data Base 


The current model data base contains data tables and parameters that 
were required by the simulation model but will not be required by the CAM 
operational model. To reduce operational model run costs, obsolete para- 
meter spaces should be removed from the data base, and the data base 
maintenance programs should be modified to reflect these changes. 


7.5 Program and Development Costs 


The estimated cost of developing a CAM operational system in terms of 
man-weeks of DSAI personnel, given the "mix" of professionals required 
for this project, as well as CDC 175 System Billing Units (SBUs), is 
provided below: 











TASK MAN-WEEKS SBUs 
Develop CAM executive 40 4,800 
Develop demand generator 10 6,000 
Develop supply generator 15 9,600 
Develop merge module 12 7 ,200 
Develop problem generator 6 3,600 
Install matrix generator ard allocators 4 2,400 
Develop output module 20 12,000 
Modification of data base programs 6 3,600 
Integrated testing i 8 20,000 

TOTAL COSTS: 121 69,200 
7.6 Project Summary 


Implementation of the operational CAM system on the Missouri Pacific 
will require close coordination between Missouri Pacific and DSAI per- 
sonnel. The following are high-level descriptions of DSAI's involvement 
in the project implementation tasks described in Section 6: 





Of the differences noted, the fir 
differences while the last is strictly 
CDC FORTRAN languages. Of the hardwar 
probably of greatest importance to CAM | 









(4) System implementation and maintenance Section 8 


(based on 5 C.P. minutes/day) 26 15,000 





System functional requirements 












The functional requirements document for the enhanced Car Dis- 
tribution System will provide the basis for a mutual under- 
standing of system capabilities between model developers, car 
distributors, and railroad management. 







(5) Model execution CONVERSION OF THE CAR ASSIGNMENT MODEL TO AN IBM 3033 COMPUTER 


(based on 5 C.P. minutes/day) -- 364 ,000 











8.1 Introduction 8.2.1 Register Sizes 





















TOTAL COSTS: 172 474,600 













IBM utilizes 32-bit internal regis 


This section outlines and describes the problems and tasks involved : 
registers. 


in converting the CAM from the CDC computer System to the Missouri 
Pacific IBM 3033 computer system. Estimates of the costs of such a con- 
version are also provided. 


The data requirements of the system must also be described to 
ensure that the described functional requirements can be met and 
that a mutual understanding is achieved. DSAI personnel will 
work closely with Missouri Pacific personnel in the development 
of the system data requirements to ensure that the logical 
representation of demands and supplies to be given to the CAM 
and the information content of interface records are consistent 
with meeting railroad requirements. 


















Although internal register size di 
version problem, the effect of the diff 
FORTRAN is a word-oriented language and 
of a FORTRAN variable is generally lim 
registers of the computer on which it i 
size of FORTRAN variables are particul 
the CAM, that must deal with a large 
limited precision. 














It is important to note that in the context of this section the word 
"conversion" is used in its most general sense. Functionally, the CAM 
can be converted to operate on the IBM 3033. However, the conversion 
will require such extensive redesign of the current CAM data structures 
that the conversion effort will involve a reprogramming of the entire CAM 
system. 





















(2) Program development 







DSAI will develop the operational CAM system as described in 
paragraphs 7.2 through 7.4. The development effort includes the 
design, coding, testing, and documentation of operating system 
modules. 







To allocate, efficiently, the storag 
IBM FORTRAN permits the declaration of 
lengths of 8, 16, or 32 bits. The 
storage in accordance with the declare 
priate object code for manipulating dif 
automatically generated. 


Extensive redesign and reprogramming of the CAM is required largely 
for two reasons: 























O The hardware differences between the IBM and CDC computer sys- 
tems as reflected in their respective FORTRAN languages will 
require an extensive redesign of the CAM data structures and use 
of computer memory. 











(3) Functional testing 











Functional testing refers to the execution of the MoPac- 
developed software and the operational CAM system in a real- 
time, parallel mode of operation. 


In CDC FORTRAN all binary integer 
quantities. Through the use of special 
program may pack several variables of 
named 60-bit variable. In CDC FORTRAN d 
be manipulated but all such manipulatio 


gram executable statements rather than 
statements. 







O The IBM FORTRAN language lacks the ability to manipulate data in 
single bit parcels. 












(4) System implementation and maintenance 











The FORTRAN language differences between the two systems impact so 
greatly on the CAM that it is doubtful that FORTRAN is an appropriate 
implementation language for the CAM on the IBM computer. In theory, IBM 
assembly language subprograms could be used in conjunction with FORTRAN 
code to perform the bit manipulation tasks required by the CAM. In prac- 
tice, the use of assembly language is probably impractical due to the 
increased computational and maintenance costs that would be incurred. 










DSAI involvement in system implementation will consist of 
establishing the CAM static data base utilizing Missouri Pacific 
provided inputs and periodically updating the data base as 
required. DSAI will also provide advice on use of the model and 
maintenance of the CAM system should this be required during the 
implementation test period. 





























Although both IBM and CDC FORTRAN 
utilization of computer storage, the tec 
completely incompatible. As a result, 
FORTRAN would require a major restruct 
Complete recoding to account for the new 














For a variety of technical reasons the PL/I programming language is 
probably a more appropriate implementation language for the CAM on an IBM 

= System. Section 8.2 provides a technical discussion of the hardware and 
software differences between the CDC and IBM systems and the rationale 
for selecting PL/I as the CAM implementation language. Section 8.3 out- 
lines the tasks involved in conversion of the CAM in the PL/I language, 
and section 8.4 provides cost estimates for the conversion tasks. 


1.1 Project costs 






Dedalo Character Sets 






d Total estimated costs for development, implementation, and one year's 


i of an operational CAM model are given below: " 
pu IBM utilizes the 8-bit EBCDIC char: 


character set. The internal characte 
different. 











MAN-WEEKS* SBUs* 

















1) System functional requirements 10 
( y 9 The larger IBM character size in cc 


Size further exacerbates the difficulty « 
to IBM hardware. An IBM FORTRAN variable 
a CDC variable can contain 10 character 
Size and collating sequence of alphanur 
revision of all internal interface recor 
numeric data. 







8.2 Systems Differences and CAM Conversion 






(2) Program development 121 65,600 





In this section four major differences between the CDC and IBM com- 
puter systems are discussed along with the implication of these differen- 
ces as regards conversion of the CAM. The list of differences noted is 
not intended to be complete. Only those differences of particular impor- 
tance to CAM conversion are noted. 



















(3) Functional testing 15 30,000 























*The average cost of one man-week is approximately $1,600 at DSAI' s 
October 1979-September 1980 rates for the mix of personnel required. 














*SBU = $.14 to $.28 depending on priority of turnaround requested. 





1des estimated development costs for these programs. 









- 40 = 



















8.2.3 












Arithmetic 




















Revision of the CAM static data base is expected to be more complex. 
The static data base contains numerous tables that must be accessed and 
utilized by several CAM modules. The organization of these tables is 
designed to allow efficient access to tabled data and is dependent upon 
the access methodologies used in the various CAM modules. 


8.2.5 Conversion of the CAM in PL/I 
st three are essentially hardware 


a difference between the IBM and 
e differences noted, the first is 
conversion. 









During the systems desizn review, turnaround requirements for the CAM 
and the trade-offs between computational speed and central memory 
requirements will be discussed with Missouri Pacific computer systems 


personnel and car assignment personnel and appropriate changes to the CAM 
allocators will be designed 1f necessary. 











IBM utilizes two's complement arithmetic; CDC utilizes one's comple- 
ment arithmetic. The permissible range of integer and floating point 
numbers is also different. 





The PL/I language as implemented on IBM hardware is a considerably 
more powerful language than FORTRAN. In particular, the language 
supports bit string data representations and a wide variety of Boolean 
operations. PL/I also contains a variety of statements which allow the 
efficient organization of computer storage, both with respect to storage 
utilization and computational speed. Concurrent I/O and computation is 
also possible via multi-tasking features of the language. 




























































































Redesigning data base records will involve changes to both the size 
and the organization of some tables due to changes in the way they will 
be accessed. For example, data stored as bit strings must be designed to 
align these strings on word boundaries and two dimensional tables should 
be designed to minimize the indexing operations required to access them. 


Although the arithmetic differences between the IBM and CDC computers 
are not anticipated to be a major conversion problem, such differences 
could cause subtle errors that would be difficult to detect during con- 
version. 


8.3.2 Reprogramming 





.ers; CDC utilizes 60-bit internal 

























Reprogramming CAM routines will generally involve two steps: 






















PL/I offers all of the functional features available in CDC FORTRAN 
and, in most cases, in a more convenient form. Furthermore, conversion 
of the CAM to the PL/I language would result in a system that would be 
considerably more cost effective to maintain and modify since assembly 
language code could be entirely avoided. Thus, PL/I is a far more appro- 
priate language in which to code the CAM than the IBM FORTRAN language. y 


fferences are not a priori a con- 
erence on the FORTRAN larguage is. 
the information-carrying, capacity 
ited by the size of the internal 
s implemented. Differences in the 
arly important in programs, like 
| number of integer variables of 















(1) A redefinition of the routine 3eclarative statements to redefine 
table lengths and types and to explicitly define arrays that are 
now packed into tables. 


For example, on a one's complement machine, algebraic negation is 
equivalent to a bit-by-bit logical complement of a binary number; on a 
two's complement machine, this is not true. CAM logic makes extensive 
use of Boolean operations on packed one-bit variables, and such variables 
. may be complemented using either algebraic negation or logical comple- 
mentation on CDC hardware. On IBM hardware, these algebraic and logical 
operations are not equivalent and subtle errors could occur if CAM pro- 
gram statements that depend on their being equivalent were inadvertently 
utilized in an IBM versiou of the CAM. 















a In order to accommodate assignment parameters for multiple car 
fleets, it will also be necessary to expand the static data base. The 
current static data base is structured to accommodate the assignment 

` parameters for only one fleet of cars. Multiple fleets could be accom- 
modated through the use of multiple dictionaries (one for each fleet), 


however, this would introduce considerable redundancy among dictionaries 
and complicate dictionary maintenance tasks. 




















































(2) A line for line recoding of the routine with appropriate changes 
to account for new data structures and PL/I statement forms. 































DSAI recommends that the CAM be reprogrammed in the PL/I language in 
the process of converting the model to the IBM system. Cost estimates 
for converting the CAM provided in Section 8.4 assume that PL/I will be 


the language utilized for CAM implementation on the Missouri Pacific IBM 
systems. 


A major portion of the reprogramming effort will involve the con- 
version of those modules that require minimal modification for the pilot 
study implementation: the model data base maintenance routines, pié + 
generators, and allocators. These modules will undergo minimal recoding 
during the development of the CDC version of the operational CAM system 
and will require the most revision when converted to IBM equipment. 








ze required for integer variables, 

integer binary variables having 
compiler automatically allocates 
d size of each variable. Appro- 
ferent sized data parcels is also 





It will probably be necessary to split the data base into two parts: 
one part carrying information that is independent of the fleet being 
assigned, and a second part carrying fleet dependent parameters. For 
example, routing information such as transit times, block breakup points, 
and transshipment cost parameters are independent of the type of car 
being moved. Other parameters, such as preferred foreign ownerships, 
back haul policies, etc., may be dependent upon the general type of car 
being assigned; i.e., boxes, flats, gondolas, etc. One of the principal 
tasks in the system design review will be to identify fleet dependent and 
independent data base parameters and to determine the best method of 
Storing and accessing these parameters on the static data base. 










8.2.4 Bit String Manipulations 





















































IBM FORTRAN has no facility for manipulating bit strings, CDC FORTRAN 
does. 






8.3 Conversion Tasks 



































It should be possible to simplify the recoding required for con- 
version of those modules that are heavily modified during the development 
of the CDC version of the operational system. If the new codes are 
designed with conversion in mind, incompatible coding can be pp Pad 
isolated, thereby simplifying conversion. Recoding of new CDC " 
will still be necessary due to word size and language differences, bu 
the task can be greatly simplified if the CDC versions of the modules are 


properly structured. 











This section outlines and provides a brief description of the tasks 
required to convert the CAM to the IBM 3033 system. 













As indicated above, CAM makes extensive use of Boolean operations on 
packed one-bit variables or bit strings. For example, model ownership 
constraints such as demand eligible ownerships, backhaul policy tables, 
and agency preferred foreign data are recorded both on the static data 
base and internally as bit strings 60 bits in length. Each bit repre- 
sents a model owner, and ownership tests are generally made using Boolean 
operators on all bits in a string simultaneous ly. 


variables are stored as 60-bit 
Shift and logical statements, a 
arbitrary byte size in a single 
ata parcels of arbitrary size may 
ns must be done directly by pro- 
through the use of declarative 

























































8.3.1 System Design Review 



















The first step in the conversion of the CAM will be a thorough review 


of the operational CAM system design. The review will be conducted for 
two reasons: 








Enhancement Revisions 



































Reprogramming the data base maintenance routines could involve — 
siderable program logic changes. If extensive changes to the data ase 
format are required to accommodate multiple fleets, significant portions 
of the maintenance logic may require revision as well as recoding. 


CAM car substitution logic will be redesigned so as to increase the 
number of car types that can be allocated by the model. With appropriate 
modification to the method of specifying and recording car substitution 


Specifications, limitations on the number of model car types can effec- 
tively be removed. 


Similar techniques are used throughout the model to represent and 
test model car types, agencies, and the final eligibility of each car for 
each demand. 


(1) To identify the changes that will be required in the interface 
between the major CAM modules as a result of hardware 
differences and to redesign these interfaces. 


languages permit the efficient 
hniques employed for doing so are 

conversion of the CAM to IBM 
uring of CAM data spaces and a 
data structures. 



































































The representation of such data as bit strings is used to improve 
Storage space utilization or computation speeds or both by a factor pro- 
n portionai to internal register sizes when compared to other data repre- 
sentations. On CDC machines the storage utilization and computation 
speeds can be improved by a factor of 60; on the IBM 3033, a factor of 32 
would be expected. 







(2) To redesign the car substitution logic in the CAM so as to 
increase the number of model car types and to provide other 
enhancements to the model that might be desirable. ` 


Fortunately, the data base maintenance programs are independent w 
other CAM system programs. Once the data base format has been ro 
mined, the design and programming of routines to create and maintain ^ ' 
data base can proceed independently of other CAM reprogramming tasks. 
is not even necessary that the data base maintenance routines and the CAM 


be programmed in the same language. i 










Á The modification of substitution logic will involve placing a limit 

on the number of different car types that can be specified as substitu- 
table for each car type but will result in a large increase in the total 
number of car types that can be specified. For example, the total number 
of car types might be limited to 256, but each car type could only have 
10 other car types specified as being substitutable for it. Exact limits 


will be established during the system design review in accordance with 
the needs of the Missouri Pacific railroad. 































- Required Revisions: 
icter set; CDC utilizes a 6-bit 


r collating sequence is also , 













































It is not anticipated that the contents of any of the major interface 
files of the CAM will require revision. However, significant changes in 
lengths of interface file variables and record lengths will be required 
to account for the IBM 8-bit character and 32-bit word size. Most inter- 
face files are serial and the required revisions will be fairly straight- 
forward: optimum lengths for interface variables will be determined and 
new records will be designed to contain these variables. 






















The ability to manipulate and perform Boolean operations on bit 
strings is critical to the cost-effective implementation of CAM.  IBM 
FORTRAN does not have the capability to perform these operations without 
resorting to the extensive use of assembly language  subprograms. 
Although it is theoretically possible to develop a CAM in FORTRAN and 
assembly language on the IBM 3033, the resulting system would be so 
costly to run and maintain that it probably would not be acceptable to 
railroad management. 





8.3.3 Implementation 
































injunction with its smaller word 
f converting CAM data structures 
' can contain 4 characters, while 
S. The differences in both the 
neric data will necessitate the 
ds and code that involves alpha- 










Implementation of the IBM version of the model will involve: 






















Alternate allocation strategies for the CAM will also be investigated 
during the systems design review. The current allocation module is 
designed to obtain the fastest possible computational speeds, but 
requires large amounts of central memory storage. Alternative strategies 
could be utilized which would make greater use of peripheral storage 


devices sacrificing some computational speed, but greatly reducing cen- 
tral memory requirements. 


(1) Functional testing of the model, 
























(2) Full implementation of the new model on the pilot study fleet, 
and 











(3) Implementation of the model on other fleets. 





available from the Missouri Pacific car distribution system. 


It is anticipated that the IBM conversion of the model will accept 
the same interface files and produce the same output files as the CDC 
version of the CAM. Functional testing of the IBM model will consist 
largely of parallel runs of the CDC and IBM CAM models using pilot study 
fleet data to ensure that the new model can communicate with the enhanced 
Missouri Pacific car distribution system and produce the same outputs as 


the CDC model. 


Full implementation of the IBM model on the pilot study fleet should 
be simple and straightforward, as Missouri Pacific car distributor and 
computer systems personnel will already be experienced in the use of the 
CDC version of the model. The move from the CDC version of the model to 
the IBM version should be essentially transparent to car distributors. 
Missouri Pacific computer system personnel will be heavily involved in 
the development and functional testing of the new model and the tran- 
sition from functional testing to model implementation will involve 
little more than the cessation of CDC model runs. 


Implementation of the IBM version of the CAM on other fleets could 
follow its initial implementation as rapidly as desired by the Missouri 
Pacific. Implementation for a new fleet will involve establishing new 
static data base parameters for the fleet and generating the dynamic data 
interfaces required via the enhanced car distribution system. DSAI's 
only anticipated involvement in these tasks will be to provide consul- 


tation on use of the model. 
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8.4 Cost Estimates 


Cost estimates for accomplishing the tasks described in Section 8.3 n. 
are provided below. The total elapsed time for conversion is estimated I 


to be 12 months. 
: kè ké qu 


It should be noted that the estimates of computer time requirements 
are very crude as DSAI has no experience with the compilation or execu- 
tion speeds of the PL/I compiler and object code on the IBM 3033. The 
given estimates are based on the ratio of 20 minutes of computer time per 
man-week for program conversion tasks and 69 minutes per week for 6" 


functional testing. 











IBM 3033 
MINUTES 








System design review 100 


Reprogram data base maintenance 


routines 300 


Reprogram matrix generator and 


allocators 620 


Reprogram other modules 460 


Functional testing and 


implementation 1,140 





TOTALS 2,620 
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